IBIS Macromodel Task Group

Meeting date: 15 September 2015

Members (asterisk for those attending):
ANSYS:                      * Dan Dvorscak
                            * Curtis Clark
Avago (LSI)                   Xingdong Dai
                            * Bob Miller
Cadence Design Systems:     * Ambrish Varma
                              Brad Brim
                              Kumar Keshavan
                              Ken Willis
eASIC                       * David Banas
                              Marc Kowalski
Ericsson:                     Anders Ekholm
IBM                           Steve Parker
Intel:                        Michael Mirmak
Keysight Technologies:      * Fangyi Rao
                            * Radek Biernacki
Maxim Integrated Products:    Hassan Rafat
Mentor Graphics:            * John Angulo
                            * Arpad Muranyi
Micron Technology:          * Randy Wolff
                              Justin Butterfield
QLogic Corp.                  James Zhou
                              Andy Joy
SiSoft:                     * Walter Katz
                            * Todd Westerhoff
                            * Mike LaBonte
Synopsys                      Rita Horner
Teraspeed Consulting Group:   Scott McMorrow
Teraspeed Labs:             * Bob Ross
TI:                           Alfred Chong

(Note: Agilent has changed to Keysight)

The meeting was led by Arpad Muranyi.

------------------------------------------------------------------------
Opens:

- Arpad said he wanted to discuss an editorial issue he found in the IBIS 6.1
  spec. (see below in New Discussions)

- Walter said that now that 6.1 was approved, we ought to start discussing the
  rewrite of the discussions of "ground" in the spec.
- Arpad took Walter's suggestion as a motion to untable item #9.
- Radek seconded the motion, and none were opposed.

--------------------------
Call for patent disclosure:

- None
-------------
Review of ARs:

- Arpad to draft a new version of the Info, Out, InOut BIRD and send it out.
  - Done.
  
- Mike Labonte to finalize and post Todd's minutes from September 1st.
  - Done.
-------------------------
Review of Meeting Minutes:

- Arpad: Does anyone have any comments or corrections for the minutes from
         September first? [none]
- Arpad: Motion to approve the minutes.
- Curtis: Second.
- Arpad: Anyone opposed?  [none]

- Arpad: Does anyone have any comments or corrections for the minutes from
         September eighth? [none]
- Mike L: Motion to approve the minutes.
- Arpad: Second.
- Arpad: Anyone opposed?  [none]

-------------
New Discussion:

Editorial Issue with IBIS 6.1 spec.
- Discussion: Arpad had noticed that the 6.1 spec had a section 10.3 "AMI
  Parameter Definition File Structure" and then 10.4 "Reserved Parameters For
  Data Management".  However, the "General Reserved Parameters" section (heading
  at the bottom of page 202) was not included in the table of contents and did
  not have its own section number (presumably, it should be 10.4 and subsequent
  sections' numbers incremented).  Everyone agreed that Arpad had found a
  legitimate issue.  Since it had existed prior to 6.1, everyone agreed that it
  was okay to simply fix the issue in the next revision of the spec.  Mike L.
  agreed to be the gatekeeper of the "ver6_1_known_issues.txt" file and to add
  this issue to it.
  
Item #6: Info, Out, InOut BIRD draft.
- Arpad: [sharing his new BIRD draft on the screen]
  - I have significantly rewritten the Statement of Issue and Analysis Path
    sections based on our recent discussions and changes in the spec itself
    over the past few years [this BIRD had been dormant for a while].
  - New Reserved parameter VendorSpecificParams [name change - see below]
  - Not required.
  - Illegal in version 6.1 or before.
  - Direction: Rx, Tx.
  - Format: Value, List [changed to Table - see below]
- Discussion: Parameter name.
  - Walter said that he preferred a different name for the parameter.  Arpad
    said that he wanted the name to clearly relay the message that some of these
    parameters may not be handled by all tools.  Some liked the suggestion of
    "pre-standard," but others thought it too presumptive.  Ultimately the
    group settled on "non-standard".
- Discussion: Parameter Format.
  - Bob R. had stated that he preferred a simple Boolean parameter.  Walter had
    agreed that it would be sufficient.  Others preferred a Table listing all of
    the non-standard parameters.  Todd said that reducing it to a Boolean could
    cause the model user to panic, but not tell them what the issues were.
    Radek and John preferred the parseable list of names provided by the Table,
    as opposed to free form text in a description field.  Ultimately, Bob R.
    said he was okay with the Table parameter concept.
- Arpad: Based on these discussions, I think my BIRD draft is close.
- Ambrish: Can we say "[non-standard parameters] must be listed" when we have no
           way to enforce it via the parser?
  - Is there precedent for any other spec providing a way to undermine itself?
- Todd: I understand your point, but I think we're acknowledging the speed of
        of the industry not undermining the spec.
- Ambrish: If someone unfamiliar with these discussions opens the spec, they see
           a description that opens the door to legitimizing these non-standard
           parameters.
- Todd: The goal is to shine a spotlight on such parameters for the user.
  - If something's not portable tell me what it is, what it does, and what is
    the workaround.
- Arpad: We could take an enforceable heavy-handed approach that would only
         allow parameters that are standardized and portable.
  - But then we'd be saying that to do anything new you have to take it outside
    of IBIS altogether.
  - That might have the opposite effect of what we want.  It might encourage
    people to go further outside the spec and not ever come back.
- Ambrish: What is the incentive for the model maker to draw this to a close?
  - What is the incentive to get the new parameters accepted into the standard?
  - Is there a strong incentive?
- Arpad: The incentive for the model maker is provided by their customer base.
  - If their customers want to use all different types of tools, then that
    provides the incentive.
- Bob R: One concern is it's stated in the spec but not enforceable which
       parameters must be listed.  Should all In/Out params be listed?
- Bob M: The issue is any non-standard tool-model interactions.
- Radek: Correct, this parameter is used if such behavior exists.
  - We already have noted in the spec that InOut or Out parameters in the Model
    Specific section are only to be passed to the user.  Other tool usages of
    Info, In, Out, InOut should be required to be listed in this new parameter
    table.
- Bob R: I'm not sure there's any way to check if something should have been
         included in the list and isn't.
- Bob M: I don't think you can parse a model and figure out if a tool is
         interacting in a non-standard way.
  - What about the possibility that an EDA tool and a model might interact in a
    way that doesn't involve a parameter?
  - I think we want to make every such interaction tied to a parameter, even if
    it's a dummy parameter, so that it can be listed in the table.
  - We should have a parameter associated with every silent handshake agreement.
- Walter: We have that issue now with redriver flow.
  - The current spec has a well-known error in the redriver flow description.
  - Unfortunately, the ATM has been unable to agree on the wording of a revised
    flow to fix the issue.
  - So we [SiSoft] have a private agreement with certain model makers that we
    are going to do the redriver flow the right way.  If other tools use the
    spec flow they will get different answers.
- Arpad: In that situation I'd think we should have a dummy Info parameter.
- Todd: An Info parameter that says what type of processing you expect.
- Radek/Walter: Agreed.
- Discussion: Listing all non-standard parameters.
  - Bob M. suggested that to avoid clutter we might only list one non-standard
    parameter associated with each feature.  For example, for PAM4 there were
    multiple non-standard parameters developed and only one might need to be
    added to this list.  Bob R. and John said that not listing all of them would
    cause more confusion.  Radek agreed and said clutter was not a problem.
    
Language corrections related to "ground" [untabled earlier, see above]:
- Walter: [sharing his document from a June ATM meeting presentation]
  - I think we unanimously agreed that 6.2 should say that C_comp is connected
    to the buffer local ground.
  - I think someplace in IBIS we need a statement that says any reference to
    ground connections in an I/O buffer is really a connection to the
    pd_ref or gc_ref terminal for that buffer.
- Radek: I think of it the other way around.  I think we should describe how
         the pd_ref or gc_ref is connected to the ground.
- Walter: I would like Radek to work on the wording of this statement.
  - I think if we can agree on this wording then 99% of the job is done.
- Arpad: Thank you all for joining.

AR: Mike L. to add a ver6_1_known_issues.txt to the 6.1 spec folder and add the
    issue Arpad discovered ("General Reserved Parameters" section number).
AR: Radek to propose ground connection language.

-------------
Next meeting: 22 September 2015 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
